Heterogeneous compute architecture hardware/software co-design for autonomous driving

ABSTRACT

Methods and apparatus relating to heterogeneous compute architecture hardware/software co-design for autonomous driving are described. In one embodiment, a heterogeneous compute architecture for autonomous driving systems (also interchangeably referred to herein as Heterogeneous Compute Architecture or “HCA” for short) integrates scalable heterogeneous processors, flexible networking, benchmarking tools, etc. to enable (e.g., system-level) designers to perform hardware and software co-design. With HCA system engineers can rapidly architect, benchmark, and/or evolve vehicle system architectures for autonomous driving. Other embodiments are also disclosed and claimed.

FIELD

The present disclosure generally relates to the field of electronics.More particularly, an embodiment relates to heterogeneous computearchitecture hardware/software co-design for autonomous driving.

BACKGROUND

Embedded Electronic Control Unit (ECU) systems used in the automotiveindustry may cover an extensive array of functions associated withvehicle control. For example, ECUs receive electrical signals from oneor more sensors, evaluate them, and then calculate triggering signalsfor mechanical actuators. The proliferation of ECUs has raised concernsregarding manageability of the vehicle distributed system.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is provided with reference to the accompanyingfigures. In the figures, the left-most digit(s) of a reference numberidentifies the figure in which the reference number first appears. Theuse of the same reference numbers in different figures indicates similaror identical items.

FIG. 1 illustrates various top-level components of a HeterogeneousCompute Architecture (HCA) for hardware/software co-design in autonomousdriving, according to an embodiment.

FIG. 2 illustrates a block diagram of a compute environment for HCA,according to an embodiment.

FIG. 3A illustrates a block diagram of a micro-cluster networkmanagement module for a HCA, according to an embodiment.

FIGS. 3B, 3C, and 3D illustrate components of micro-cluster data planeslices or regions for HCA, according to some embodiments.

FIGS. 4 and 5 illustrate compute node block diagrams for HCA, accordingto some embodiments.

FIG. 6 illustrates a block diagram of a scalable data ingestion FPGAcompute node for HCA, according to an embodiment.

FIG. 7 illustrates a block diagram of an ECU compute node module forHCA, according to an embodiment.

FIGS. 8 and 9 illustrates block diagrams of embodiments of computingsystems, which may be utilized in various embodiments discussed herein.

FIGS. 10 and 11 illustrate various components of processers inaccordance with some embodiments.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth inorder to provide a thorough understanding of various embodiments.However, various embodiments may be practiced without the specificdetails. In other instances, well-known methods, procedures, components,and circuits have not been described in detail so as not to obscure theparticular embodiments. Further, various aspects of embodiments may beperformed using various means, such as integrated semiconductor circuits(“hardware”), computer-readable instructions organized into one or moreprograms (“software”), or some combination of hardware and software. Forthe purposes of this disclosure reference to “logic” shall mean eitherhardware (such as logic circuitry or more generally circuitry orcircuit), software, firmware, or some combination thereof.

As mentioned above, embedded Electronic Control Unit (ECU) systems usedin the automotive industry may cover an extensive array of functionsassociated with vehicle control. For example, ECUs receive electricalsignals from one or more sensors, evaluate them, and then calculatetriggering signals for mechanical actuators. The proliferation of ECUshas raised concerns regarding manageability of the vehicle distributedsystem. Thus, consolidating functionality onto fewer ECUs with morepowerful processors may be considered. Moreover, some of these ECUsbundle important function groups together such as drivetrain, suspensionmanagement system, body, assisted/automated driving, and/orinterior/multimedia/telematics domains, which deserve carefulconsideration.

Compared to traditional software development, the design of embeddedsystems is even more challenging. In addition to the correctimplementation of the functional behavior, one has to also considernon-functional constraints such as real-time behavior, reliability, andenergy consumption. For this reason, embedded systems are often builtwith specialized, often application-specific hardware platforms. Toallow late design changes even on the hardware/software partitioning,languages and model-based design tools are required that can generateboth hardware and software from the same realization-independent model.Moreover, many embedded systems are used in safety-critical applicationswhere errors can lead to severe damages up to the loss of human lives.For this reason, formal verification is applied in many design flowsusing different kinds of formal verification methods.

Some embodiments relate to heterogeneous compute architecturehardware/software co-design for autonomous driving. In one embodiment, aheterogeneous compute architecture for autonomous driving systems (alsointerchangeably referred to herein as Heterogeneous Compute Architectureor “HCA” for short) integrates scalable heterogeneous processors,flexible networking, benchmarking tools, etc. to enable (e.g.,system-level) designers to perform hardware and software co-design. WithHCA system engineers can rapidly architect, benchmark, and/or evolvevehicle system architectures for autonomous driving.

In an embodiment, HCA utilizes a custom designed motherboard forautomotive heterogeneous architecture on which multiple compute elementscan be interconnected. This board allows a flexible networkarchitectures of single or multi-core compute units (or processors)using automotive CAN (Controller Area Network), high-speed Ethernet,and/or PCIe (Peripheral Component Interconnect express). HCA may alsoprovide custom designed CPU (Central Processing Unit, or moregenerically “processor”) compute nodes as elements of a scalableheterogeneous vehicle architecture. The CPU compute nodes can beflexibly expanded for acceleration integrating FPGA (Field ProgrammableGate Array), GPU (Graphics Processing Unit), or ASIC (ApplicationSpecific Integrated Circuit) solutions via PCIe or other interconnects.

In one embodiment, HCA provides a platform for Autonomous Driving Systemhardware/software co-development which does not exist in any commercialplatforms. The hardware flexibility in HCA can be used to speedexploratory vehicle architecture development. The benchmarking toolsetcan be used to derive informed hardware/software design elements.Further, autonomous driving development has to comply with stringentsafety, cost, and power efficiency requirements that can only beachieved with hardware/software co-design. To this end, HCA enables theability to determine computational performance across multiple processortypes as well as benefits or drawbacks of computation acceleration viaFPGA, GPU and ASICs versus traditional single-core automotivemicrocontrollers (ECU), in accordance with one embodiment. With suchflexible hardware clustering and networking configurations throughEthernet, Automotive CAN, PCIe, USB (Universal Serial Bus), or JTAG((Joint Test Action Group (developer of IEEE Standard 1149.1-1990)),automotive system designers can re-architect the complete vehicleelectronics using HCA. It is essentially a “car in a box”.

Further, the HCA system may provide an ECU board hosting a flexiblenumber of single core traditional automotive microcontrollers, which canbe stacked and programmed via CAN, Ethernet, USB (Universal Serial Bus),UART (Universal Asynchronous Receiver-Transmitter), etc. HCA can beconsidered as a framework for hardware and/or software co-design. Tomake architectural decisions, management, configuration, and monitoringelements are provided to make informed decisions regarding systemarchitecture for a particular automotive workload, allowing for totalflexibility for novel system configurations.

FIG. 1 illustrates various top-level components of a heterogeneouscompute architecture 100 for hardware/software co-design in autonomousdriving, according to an embodiment. In one embodiment, logic and/orvarious components (including one or more of the components discussedwith reference to FIG. 1) may be mounted or otherwise physically coupledto a vehicle. As discussed herein, a “vehicle” generally refers to anytransportation device capable of being operated autonomously (withlittle or no human/driver intervention), such as an automobile, a truck,a motorcycle, an airplane, a helicopter, a vessel/ship, a train, adrone, etc. whether or not the vehicle is a passenger or commercialvehicle, and regardless of the power source type (such as one or moreof: fossil fuel(s), solar energy, electric energy, chemical energy,nuclear energy, etc.) and regardless of the physical state of the powersource (e.g., solid, liquid, gaseous, etc.) used to move the vehicle.

Generally, traditional automotive systems tend to rely on a multitude ofsingle-core microprocessors or FGPA-based ECUs. In the currentcompetitive race towards mass adoption of self-driving vehicles, someautomakers and technology disruptors may aim to enhance the traditionalvehicle infrastructure with an extended suite of sensors anddata-center-like compute capabilities that can be achieved with multiplecompute platforms (such as CPUs, GPUs, FPGAs, or specialized ASICs).

Some silicon manufacturers may utilize multicore solutions forautonomous driving, e.g., with GPU based systems to provide a mix of SOC(System On Chip) and MCUs (Microcontroller Units), or CPU based systemswith FPGA and/or ASIC acceleration. Hence, while automotive hardwareplatforms are experiencing a trend toward architectural heterogeneity,modern CPUs can provide flexible hardware resources and rich instructionset for implementing a broad spectrum of compute tasks, specializedworkloads, and may motivate the introduction of alternative hardwarearchitectures with specialized circuit design to accelerate operationsand parallelism such as the techniques discussed herein with referenceto HCA.

In autonomous driving system development, some of the most challengingtasks reside in the simultaneous integration of three critical areas:supercomputing complexity, real-time performance, and functional safety.For example, developers are required to shift their focus from asoftware-centric approach toward custom hardware/software co-design toproduce a system that meets the safety, cost, and power efficiencydesign constraints of vehicles. None of the current solutions providethe proper ingredients. By contrast, HCA provides supercomputing byenabling a scalable 16× multi CPU/FPGA/GPU/ASIC scalability and thebenchmarking software needed to evaluate real-time performance in someembodiments. Also, while certain embodiments may mention a specificnumber of components/items, embodiments are not limited to thesespecific numbers, more or less components may be utilized depending onthe implementation.

For instance, one main disadvantage of the other solutions is that theymay be focused on limited compute types, and the system packaging andavailable network technologies can render flexible heterogeneousautomotive architectures impossible. And, none of the current solutionsseem to be applicable to create a heterogeneous environment, allowingproper comparisons between compute types. By contrast, comparisons aregenerally done as system vs. system where there are too many variables,making isolation of specific design considerations virtually impossible.

Referring to FIG. 1, the HCA components provide a heterogeneousarchitecture system for Autonomous Driving (AD), engineered toaccelerate system level experimentation and benchmarking of ADworkloads. It provides researchers/designers access to a “car in awhite-box”, an integrated, flexible and scalable AD system that can beused as a reconfigurable workstation or embedded platform forin-the-wild testing of vehicle system configurations. HCA is built tospeed-up development and optimization of future vehicle architectures,understanding that the current automotive architectures cannot supportthe compute, connectivity and storage requirements of fully automateddriving vehicles. In one embodiment, HCA “in-the wild testing” orembedded integration into a vehicle may be available in engineeringvehicles and not suited for production environments. In an embodiment,an HCA ruggedized chassis may include fan cooling rather than liquidcooling solutions and can be apt to evaluate hardware/softwareconfiguration and gather initial datasets, and not for prolonged use.

Architecture 100 includes a sensor environment 102, a computeenvironment 104, a Robotic Operating System (ROS) 106, and an actuationenvironment 108. These components may be assembled into an enclosure forease of transport and/or organization. The enclosure may be transparentto allow for quick visual detection, e.g., of indicators. The sensorcapture environment 102 includes one or more FPGAs with automotivesensor interface(s). The sensor capture environment 102 may be scalable(e.g., modular), with synchronized and/or flexible sensor(s). Forexample, each module in the sensor capture environment 102 may includeone or more cameras (e.g., 16 High Dynamic Range (HDR) cameras in anembodiment), a Controller Area Network (CAN) bus, and an Ethernetinterface. As will be further discussed herein, the compute environment104 may have a modular design, with each module (also referred to hereinas a “region” or “slice” as will be further discussed with reference toFIG. 3B) including one or more processors, e.g., having one or morecores. The processor(s) may run various software program(s) including,for example, a Robotic Operating System (ROS) 106 or components thereof.

The compute environment 104 may include a compute tray (ormicro-cluster) provided on a motherboard for several (e.g., 16) computenodes connected via Ethernet network and CAN with (e.g., 16)reconfigurable PCIe connections for CPU accelerators. The computeenvironment may utilized one or more different types of processors invarious embodiments. For example, multi-core as well as single-coreprocessors may be used.

Actuation environment or test-bed (e.g., ECU Test-Bed) 108 includes areconfigurable ECU test bed (e.g., including 48 ECUs in CAN network(s)).For example, the test-bed provides a gateway and (e.g., 48) stackableLPC™ cards that contain LPC1000™ family automotive grademicrocontrollers (MCUs) networked via automotive CAN bus. Other LPC MCUsmay also be used such as LPC800, LPC1100, LPC54000, etc. Eachmicrocontroller includes a processor core, static RAM (Random AccessMemory) memory, flash memory, debugging interface, and variousperipherals.

In an embodiment, the HCA software architecture includes a middlewarelayer that provides a set of APIs (Application Program Interfaces) tohigher level applications such as a Robotic Operating System (ROS) 106software stack. The APIs allow for configuring and retrieving data froma multi-modal set of automotive sensors (including for example one ormore of: a camera, radar, Light Detection And Ranging (LIDAR) sensor,Inertial Measurement Units (IMUS), etc.). Additionally, the middlewarecan be designed to abstract the complexity and low level details of thesensor interfaces through the easy to use APIs. The ROS software stackprovides a standardized and flexible output which can be leveraged byexisting AD algorithms and infrastructure. For example, the ROS 106 maybe utilized for object detection, obstacle prediction, trajectoryplanning, etc. to support AD.

Accordingly, in some embodiments, HCA can provide: (1) a flexible andscalable system with modular hardware components that can be flexiblyprogrammed, configured, and/or networked for particular needs; and/or(2) a reference development and benchmarking platform equipped withworkload analysis and reporting tools. HCA's design can address existinglimitations of automotive platforms with regards to vehicle electronics,sensor data acquisition. and autonomous driving software development.

FIG. 2 illustrates a block diagram of a compute environment for HCA,according to an embodiment. As mentioned above, HCA can provide flexiblehardware reconfiguration. The compute environment shown in FIG. 2, alsoreferred to herein as a micro-cluster (or ucluster) provides a hardwarecanvas for configuration of interconnected heterogeneous computemodules. Each of the CPU modules can belong to differentmicroarchitecture families, e.g. Atom® (also called “Denverton™”), Xeon®(also referred to as Broadwell™-DE and SkyLake™-D), or iCore™-7. Whilevarious figures or discussions herein may refer to a specific part ordevice, embodiments are not limited to these specific selections and anyother component with the same or similar functionality may be used invarious implementations.

The micro-cluster includes an Ethernet switch tray (FIG. 2—item 1) thatinterconnects through a 10 GB Ethernet switch the 16 CPU compute nodespopulated in compute slots (FIG. 2—item 2). Each CPU slot can beextended with peripherals such as FPGA, GPU or other hardwareaccelerator (e.g., ASIC) via PCI Express (FIG. 2—item 3). The computeboard of FIG. 2 has a management network that allows configuration,de/activation of the network, individual component nodes as well aspower and I/O management from the Chassis Management Module (CMM) (FIG.2—item 4). This module provides a high level user program (e.g., CMM)for controlling power, monitoring power use, temperature monitoring,etc. for each compute node or region.

Each compute node can be considered as a full computing server. Anycombination of compute nodes can be arranged in a cluster. Each nodealso has four 10G NIC (Network Interface Controller) connections thatcouple to the integrated (e.g., 10G) Ethernet switch, a 72 port 10G(e.g., Fulcrum Alta) Ethernet Switch that not only connects all (e.g.,16) nodes, it also has (e.g., eight 10G) back panel connections tocouple to a telematics control unit for links to the world outside avehicle.

FIG. 3A illustrates a block diagram of a micro-cluster networkmanagement module for a HCA, according to an embodiment. An (e.g., 1 GB)Ethernet network may also be added for management use, e.g., using threeMarvell 88E190X switches linked as illustrated in FIG. 3A. Themanagement network allows the management module (e.g., CMM) directaccess (via high level protocols such as Secure Socket Shell (SSH) andVirtual Network Connection (VNC)) for reconfiguring compute nodes (e.g.,via each region controller), e.g., without obstructing or hindering theapplication network operations.

FIG. 3B illustrates a block diagram of a micro-cluster data plane sliceor region for HCA, according to one embodiment. More specifically, eachset of (e.g., 4) nodes in the compute tray is referred to herein as a“region” (or “slice” interchangeably). In each region, the set of nodesis connected via a PCIe switch to four PCIe slots as illustrated in FIG.3B.

Moreover, FIG. 3B illustrates how the CPU card connectors route (e.g.,four 10 GB) Ethernet connections (350) to the Ethernet switch as well asCAN Bus connections. This allows each of the compute nodes to use ahigh-speed connection, e.g., to allow the compute nodes to act as acomputing cluster to distribute autonomous driving workloads, or as amulti-core individual component communicating via the CAN bus (352) toother vehicle components. The interface to the CAN interface may beprovided by an ARM Cortex microcontroller (e.g., LPC1788 or other LPCMCU) via Universal Serial Bus (USB) 359 to each node. Each of the nodesis routed via PCIe 3rd Gen 354 to a PCIe switch 355 that can beconfigured to connect each of the nodes to each of the PCIeslots/connectors. Each slot may be a mechanical PCIe ×16 (but may beelectrical ×8) 356. With the PCIe Switch, one can assign any of the PCIeslots to any of the CPU nodes/connectors. Each of the nodes has 16 Lanesgoing to the PCIe switch, if available. Some nodes such as Denverton mayhave eight PCIe lanes going to the PCIe Switch. Using different CPUnodes in each slot, it makes research easier with the same PCIeperipherals such as FPGA, GPU, or other hardware accelerator (e.g.,ASICs) and different CPU architectures. As discussed below, each CPUnode architecture may also be very similar to keep results asarchitecturally specific as possible. This allows users/designers of HCAto truly compare these architectures along with FPGA, GPUs, etc. withtheir workloads.

Further, by using each type of CPU/compute node or combination ofseveral Atom and/or Xeon nodes, a workload can be run and tested for thenode's ability to run that workload with respect to performance andpower consumption (e.g., power monitoring may be built into themicro-cluster design). Each CPU node may be designed as a full SOCserver equipped with: (a) on-board memory, where the maximum memorydepends on the CPU type; (2) M.2 or SSD (or other non-volatile memory)storage, with PCIe ×4 and SATA (Serial Advanced Technology Attachment)supported. e.g., on 1 connection; (c) USB connection, e.g., mini 2.0connector on Broadwell-DE node and USB Type C on newer boards (Broadwellis USB 2. Denverton has USB 2 and USB 3 via the type C, and newer suchas Skylake are USB 3.1); (d) debug connector, which provides a PCIe(e.g., ×1) and serial port to a special debug board (which can use amini HDMI (High Definition Multimedia Interface) to HDMI cable); and/or(e) firmware/debug headers, which may have MIPI60, Dediprog™ (for BIOS(Basic Input Output System)), and EC to program the H8S microcontroller(for powering up a node).

Additionally, in some embodiments, each node may include the followingconnections: (i) PCIe, e.g., 16 PCIe lanes to the PCIe switch and thento PCIe slots (see, for example, region description above); (ii) CAN buswith USB to an LPC1768 CAN bus controller giving access to two CAN busesthat run between all nodes with front panel and mid board connectors(e.g., M.12); (iii) 10G Network, such as 4×10G connections to theEthernet switch tray (e.g., 72 port 10G switch), where some nodes mayhave less connections such as Broadwell-DE that may have two; (iv)management LAN (Local Area Network), e.g., a 1G connection between allnodes, the CMM, and SCP (Secure Copy) for using SSH and otherconnections between nodes separate from the 10G LAN; (v) UART (UniversalAsynchronous Receiver-Transmitter) and I2C (Interface to Communicate),for use in powering on a node, programming firmware, and debug, wherethese connections go back to the CMM as illustrated in FIG. 3C. It isnot expected that firmware will need updating but if it does it can bedone via the CMM program on the CMM module.

The aforementioned configurations/connections are shown in FIG. 3D,which illustrates components of micro-cluster data plane slices,according to some embodiments. As shown in FIG. 3D, each board/sliceincludes a region controller and various USB, CAN bus, UART, and I2Cconnections between various components to facilitate communication.

FIG. 4 illustrates a Denverton compute node block diagram for HCA,according to an embodiment. The Denverton node is designed forautomotive workloads characterization. This SOC can be applied toautomotive products and can be a part of partial automation orhighly-automated driving functions such as Highway Autopilot (where avehicle traverses a highway autonomously). In the illustrate embodiment,the Denverton NS CPUs are used. Various components are shown includingthe CPU module card (e.g., hosting the Denverton C3000 SOC), the memoryinterfaces, DIMM (Dual In-Line Memory Module) connector to themicro-cluster and rest of interfaces, as discussed with reference to thecompute nodes of previous figures.

FIG. 5 illustrates a Broadwell-DE CPU compute node block diagram forHCA, according to an embodiment. The Broadwell Node is based on the XeonD1500 also known as Broadwell-DE. It is similar to the Denverton node ofFIG. 4 in design to help in comparison benchmarking. Various componentsare shown in FIG. 5 including the CPU module card (e.g., hosting theBroadwell-DE CPU), the memory interfaces, DIMM connector to themicro-cluster and rest of interfaces, as discussed with reference to thecompute nodes of previous figures. In FIGS. 4 and 5, a JTAG (Joint TestAction Group (developer of IEEE Standard 1149.1-1990)) may be used toverifying designs and testing printed circuit boards after manufacture.

FIG. 6 illustrates a block diagram of a scalable data ingestion FPGAcompute node for HCA, according to an embodiment. More particularly,FIG. 6 shows an FPGA compute node for acceleration of data ingestionthat carries the function of multi sensor data synchronization andpreprocessing. This compute node is programmable via PCIe interface fromthe compute node (CPU) that it is associated to as well as from themanagement module (e.g., CMM). As shown, camera synchronization may bedone via a CSI-MIPI interface. And, PCIe may be used tocontrol/configure the sensor plane via I2C, SCCB (Serial Camera ControlBus), CSR (Control and Status Register), etc.

FIG. 7 illustrates a block diagram of an ECU compute node module forHCA, according to an embodiment. The ECU module shown in FIG. 7 may beprovided in a stackable configuration (e.g., using LPC family ofprocessors such as discussed previously). The module may also beconfigured to be a clock master or slave in various embodiments. The ECUcompute nodes are programmable MCU microcontrollers with built in JTAG,USB, and CAN connectivity as well as a MicroSD for storage. They can beprogrammed with an RTOS (Real-Time Operating System) such as AUTOSAR™((Automotive Open System Architecture)) software to perform a particularvehicle function e.g. brake control. Multiple modules as displayed inFIG. 7 can be stacked into a carrier board that enables 48 of theseunits in an embodiment.

To aid with system development of HCA, a workload benchmarking frameworkmay be provided that uses (e.g., Linux®) tools for tracing performanceand generating graphs for single or multiple compute nodes. The toolsset may make use of Vmstat™, Blktrace™, Tcpdump™ and can be extendedwith custom debugging/tracing tools. In one embodiment, a configurationfile may be provided where the user can modify the parameters for thetools and a launch the file for targeted/distributed monitoring ofperformance. Once the workload is finished, the tool may allow forgathering of data and visualizations to help analyze bottlenecks andother issues. This data can be then exported to other frameworks as .csvor .png files. For application monitoring, interfaces may be providedwith ROS as well as sensor middleware logs.

FIG. 8 illustrates a block diagram of an SOC package in accordance withan embodiment. As illustrated in FIG. 8, SOC 802 includes one or moreCentral Processing Unit (CPU) cores 820, one or more Graphics ProcessorUnit (GPU) cores 830, an Input/Output (I/O) interface 840, and a memorycontroller 842. Various components of the SOC package 802 may be coupledto an interconnect or bus such as discussed herein with reference to theother figures. Also, the SOC package 802 may include more or lesscomponents, such as those discussed herein with reference to the otherfigures. Further, each component of the SOC package 820 may include oneor more other components, e.g., as discussed with reference to the otherfigures herein. In one embodiment, SOC package 802 (and its components)is provided on one or more Integrated Circuit (IC) die, e.g., which arepackaged into a single semiconductor device.

As illustrated in FIG. 8, SOC package 802 is coupled to a memory 860 viathe memory controller 842. In an embodiment, the memory 860 (or aportion of it) can be integrated on the SOC package 802.

The I/O interface 840 may be coupled to one or more I/O devices 870,e.g., via an interconnect and/or bus such as discussed herein withreference to other figures. I/O device(s) 870 may include one or more ofa keyboard, a mouse, a touchpad, a display, an image/video capturedevice (such as a camera or camcorder/video recorder), a touch screen, aspeaker, or the like.

FIG. 9 is a block diagram of a processing system 900, according to anembodiment. In various embodiments the system 900 includes one or moreprocessors 902 and one or more graphics processors 908, and may be asingle processor desktop system, a multiprocessor workstation system, ora server system having a large number of processors 902 or processorcores 907. In on embodiment, the system 900 is a processing platformincorporated within a system-on-a-chip (SoC or SOC) integrated circuitfor use in mobile, handheld, or embedded devices.

An embodiment of system 900 can include, or be incorporated within aserver-based gaming platform, a game console, including a game and mediaconsole, a mobile gaming console, a handheld game console, or an onlinegame console. In some embodiments system 900 is a mobile phone, smartphone, tablet computing device or mobile Internet device. Dataprocessing system 900 can also include, couple with, or be integratedwithin a wearable device, such as a smart watch wearable device, smarteyewear device, augmented reality device, or virtual reality device. Insome embodiments, data processing system 900 is a television or set topbox device having one or more processors 902 and a graphical interfacegenerated by one or more graphics processors 908.

In some embodiments, the one or more processors 902 each include one ormore processor cores 907 to process instructions which, when executed,perform operations for system and user software. In some embodiments,each of the one or more processor cores 907 is configured to process aspecific instruction set 909. In some embodiments, instruction set 909may facilitate Complex Instruction Set Computing (CISC), ReducedInstruction Set Computing (RISC), or computing via a Very LongInstruction Word (VLIW). Multiple processor cores 907 may each process adifferent instruction set 909, which may include instructions tofacilitate the emulation of other instruction sets. Processor core 907may also include other processing devices, such a Digital SignalProcessor (DSP).

In some embodiments, the processor 902 includes cache memory 904.Depending on the architecture, the processor 902 can have a singleinternal cache or multiple levels of internal cache. In someembodiments, the cache memory is shared among various components of theprocessor 902. In some embodiments, the processor 902 also uses anexternal cache (e.g., a Level-3 (L3) cache or Last Level Cache (LLC))(not shown), which may be shared among processor cores 907 using knowncache coherency techniques. A register file 906 is additionally includedin processor 902 which may include different types of registers forstoring different types of data (e.g., integer registers, floating pointregisters, status registers, and an instruction pointer register). Someregisters may be general-purpose registers, while other registers may bespecific to the design of the processor 902.

In some embodiments, processor 902 is coupled to a processor bus 910 totransmit communication signals such as address, data, or control signalsbetween processor 902 and other components in system 900. In oneembodiment the system 900 uses an exemplary ‘hub’ system architecture,including a memory controller hub 916 and an Input Output (I/O)controller hub 930. A memory controller hub 916 facilitatescommunication between a memory device and other components of system900, while an I/O Controller Hub (ICH) 930 provides connections to I/Odevices via a local I/O bus. In one embodiment, the logic of the memorycontroller hub 916 is integrated within the processor.

Memory device 920 can be a dynamic random access memory (DRAM) device, astatic random access memory (SRAM) device, flash memory device,phase-change memory device, or some other memory device having suitableperformance to serve as process memory. In one embodiment the memorydevice 920 can operate as system memory for the system 900, to storedata 922 and instructions 921 for use when the one or more processors902 executes an application or process. Memory controller hub 916 alsocouples with an optional external graphics processor 912, which maycommunicate with the one or more graphics processors 908 in processors902 to perform graphics and media operations.

In some embodiments, ICH 930 enables peripherals to connect to memorydevice 920 and processor 902 via a high-speed I/O bus. The I/Operipherals include, but are not limited to, an audio controller 946, afirmware interface 928, a wireless transceiver 926 (e.g., Wi-Fi,Bluetooth), a data storage device 924 (e.g., hard disk drive, flashmemory, etc.), and a legacy I/O controller 940 for coupling legacy(e.g., Personal System 2 (PS/2)) devices to the system. One or moreUniversal Serial Bus (USB) controllers 942 connect input devices, suchas keyboard and mouse 944 combinations. A network controller 934 mayalso couple to ICH 930. In some embodiments, a high-performance networkcontroller (not shown) couples to processor bus 910. It will beappreciated that the system 900 shown is exemplary and not limiting, asother types of data processing systems that are differently configuredmay also be used. For example, the I/O controller hub 930 may beintegrated within the one or more processor 902, or the memorycontroller hub 916 and I/O controller hub 930 may be integrated into adiscreet external graphics processor, such as the external graphicsprocessor 912.

FIG. 10 is a block diagram of an embodiment of a processor 1000 havingone or more processor cores 1002A to 1002N, an integrated memorycontroller 1014, and an integrated graphics processor 1008. Thoseelements of FIG. 10 having the same reference numbers (or names) as theelements of any other figure herein can operate or function in anymanner similar to that described elsewhere herein, but are not limitedto such. Processor 1000 can include additional cores and includingadditional core 1002N represented by the dashed lined boxes. Each ofprocessor cores 1002A to 1002N includes one or more internal cache units1004A to 1004N. In some embodiments each processor core also has accessto one or more shared cached units 1006.

The internal cache units 1004A to 1004N and shared cache units 1006represent a cache memory hierarchy within the processor 1000. The cachememory hierarchy may include at least one level of instruction and datacache within each processor core and one or more levels of sharedmid-level cache, such as a Level 2 (L2), Level 3 (L3), Level 4 (L4), orother levels of cache, where the highest level of cache before externalmemory is classified as the LLC. In some embodiments, cache coherencylogic maintains coherency between the various cache units 1006 and 1004Ato 1004N.

In some embodiments, processor 1000 may also include a set of one ormore bus controller units 1016 and a system agent core 1010. The one ormore bus controller units 1016 manage a set of peripheral buses, such asone or more Peripheral Component Interconnect buses (e.g., PCI, PCIExpress). System agent core 1010 provides management functionality forthe various processor components. In some embodiments, system agent core1010 includes one or more integrated memory controllers 1014 to manageaccess to various external memory devices (not shown).

In some embodiments, one or more of the processor cores 1002A to 1002Ninclude support for simultaneous multi-threading. In such embodiment,the system agent core 1010 includes components for coordinating andoperating cores 1002A to 1002N during multi-threaded processing. Systemagent core 1010 may additionally include a power control unit (PCU),which includes logic and components to regulate the power state ofprocessor cores 1002A to 1002N and graphics processor 1008.

In some embodiments, processor 1000 additionally includes graphicsprocessor 1008 to execute graphics processing operations. In someembodiments, the graphics processor 1008 couples with the set of sharedcache units 1006, and the system agent core 1010, including the one ormore integrated memory controllers 1014. In some embodiments, a displaycontroller 1011 is coupled with the graphics processor 1008 to drivegraphics processor output to one or more coupled displays. In someembodiments, display controller 1011 may be a separate module coupledwith the graphics processor via at least one interconnect, or may beintegrated within the graphics processor 1008 or system agent core 1010.

In some embodiments, a ring based interconnect unit 1012 is used tocouple the internal components of the processor 1000. However, analternative interconnect unit may be used, such as a point-to-pointinterconnect, a switched interconnect, or other techniques, includingtechniques well known in the art. In some embodiments, graphicsprocessor 1008 couples with the ring interconnect 1012 via an I/O link1013.

The exemplary I/O link 1013 represents at least one of multiplevarieties of I/O interconnects, including an on package I/O interconnectwhich facilitates communication between various processor components anda high-performance embedded memory module 1018, such as an eDRAM (orembedded DRAM) module. In some embodiments, each of the processor cores1002 to 1002N and graphics processor 1008 use embedded memory modules1018 as a shared Last Level Cache.

In some embodiments, processor cores 1002A to 1002N are homogenous coresexecuting the same instruction set architecture. In another embodiment,processor cores 1002A to 1002N are heterogeneous in terms of instructionset architecture (ISA), where one or more of processor cores 1002A to1002N execute a first instruction set, while at least one of the othercores executes a subset of the first instruction set or a differentinstruction set. In one embodiment processor cores 1002A to 1002N areheterogeneous in terms of microarchitecture, where one or more coreshaving a relatively higher power consumption couple with one or morepower cores having a lower power consumption. Additionally, processor1000 can be implemented on one or more chips or as an SoC integratedcircuit having the illustrated components, in addition to othercomponents.

FIG. 11 is a block diagram of a graphics processor 1100, which may be adiscrete graphics processing unit, or may be a graphics processorintegrated with a plurality of processing cores. In some embodiments,the graphics processor communicates via a memory mapped I/O interface toregisters on the graphics processor and with commands placed into theprocessor memory. In some embodiments, graphics processor 1100 includesa memory interface 1114 to access memory. Memory interface 1114 can bean interface to local memory, one or more internal caches, one or moreshared external caches, and/or to system memory.

In some embodiments, graphics processor 1100 also includes a displaycontroller 1102 to drive display output data to a display device 1120.Display controller 1102 includes hardware for one or more overlay planesfor the display and composition of multiple layers of video or userinterface elements. In some embodiments, graphics processor 1100includes a video codec engine 1106 to encode, decode, or transcode mediato, from, or between one or more media encoding formats, including, butnot limited to Moving Picture Experts Group (MPEG) formats such asMPEG-2, Advanced Video Coding (AVC) formats such as H.264/MPEG-4 AVC, aswell as the Society of Motion Picture & Television Engineers (SMPTE)421M/VC-1, and Joint Photographic Experts Group (JPEG) formats such asJPEG, and Motion JPEG (MJPEG) formats.

In some embodiments, graphics processor 1100 includes a block imagetransfer (BLIT) engine 1104 to perform two-dimensional (2D) rasterizeroperations including, for example, bit-boundary block transfers.However, in one embodiment, 11D graphics operations are performed usingone or more components of graphics processing engine (GPE) 1110. In someembodiments, graphics processing engine 1110 is a compute engine forperforming graphics operations, including three-dimensional (3D)graphics operations and media operations.

In some embodiments, GPE 1110 includes a 3D pipeline 1112 for performing3D operations, such as rendering three-dimensional images and scenesusing processing functions that act upon 3D primitive shapes (e.g.,rectangle, triangle, etc.). The 3D pipeline 1112 includes programmableand fixed function elements that perform various tasks within theelement and/or spawn execution threads to a 3D/Media sub-system 1115.While 3D pipeline 1112 can be used to perform media operations, anembodiment of GPE 1110 also includes a media pipeline 1116 that isspecifically used to perform media operations, such as videopost-processing and image enhancement.

In some embodiments, media pipeline 1116 includes fixed function orprogrammable logic units to perform one or more specialized mediaoperations, such as video decode acceleration, video de-interlacing, andvideo encode acceleration in place of, or on behalf of video codecengine 1106. In some embodiments, media pipeline 1116 additionallyincludes a thread spawning unit to spawn threads for execution on3D/Media sub-system 1115. The spawned threads perform computations forthe media operations on one or more graphics execution units included in3D/Media sub-system 1115.

In some embodiments, 3D/Media subsystem 1115 includes logic forexecuting threads spawned by 3D pipeline 1112 and media pipeline 1116.In one embodiment, the pipelines send thread execution requests to3D/Media subsystem 1115, which includes thread dispatch logic forarbitrating and dispatching the various requests to available threadexecution resources. The execution resources include an array ofgraphics execution units to process the 3D and media threads. In someembodiments, 3D/Media subsystem 1115 includes one or more internalcaches for thread instructions and data. In some embodiments, thesubsystem also includes shared memory, including registers andaddressable memory, to share data between threads and to store outputdata.

The following examples pertain to further embodiments. Example 1includes an apparatus comprising: a plurality of processors, coupled toa Controller Area Network (CAN) Bus, to communicate with one or morecomponents of a vehicle; and a region controller, coupled to each of theplurality of processors via a point-to-point interconnect, wherein theplurality of processors, the CAN Bus, and the region controller form afirst compute module, wherein the region controller is to manageoperations of one or more components of the first compute module,wherein the plurality of processors are capable to communicate with eachother and one or more other components of the first compute module via ahigh speed interface, while the plurality of processors are capable tocommunicate with the one or more vehicle components via the CAN Bus,wherein the high speed interface is to provide faster data communicationthan the CAN Bus, wherein the region controller is coupled to a ChassisManagement Module (CMM), wherein the CMM is capable to controloperations of one or more components of the first compute module throughthe region controller.

Example 2 includes the apparatus of example 1, wherein the one or morevehicle components comprise one or more of: a camera, a LIDAR, a radar,an Inertial Measurement Unit (IMU), or an ultrasonic device. Example 3includes the apparatus of example 1, wherein the CMM is to: controlpower consumption of the one or more components of the first computemodule and one or more other compute modules; monitor power consumptionof the one or more components of the first compute module and the one ormore other compute modules; or monitor temperature values for the firstcompute module and the one or more other compute modules. Example 4includes the apparatus of example 1, further comprising a mastercontroller, coupled to the region controller of the first compute moduleand region controller of a second compute module, to manage operationsof one or more components of the first compute module and the secondcompute module. Example 5 includes the apparatus of example 1, furthercomprising a Peripheral Component Interconnect express (PCIe) switch,coupled to each of the plurality of processors, to facilitatecommunication between the plurality of processors and one or more PCIeconnectors, wherein the one or more PCIe connectors are coupled to oneor more of: a Field-Programmable Gate Array (FPGA), a Graphics ProcessorUnit (GPU), a hardware accelerator or Application Specific IntegratedCircuit (ASIC) device, or a different processor.

Example 6 includes the apparatus of example 5, wherein the differentprocessor comprises a different architecture from an architecture of atleast one of the plurality of processors. Example 7 includes theapparatus of example 1, wherein the point-to-point interconnectcomprises an Ethernet interconnect, Universal AsynchronousReceiver-Transmitter (UART) interface, a Universal Serial Bus (USB), oran Interface to Communicate (I2C) interconnect. Example 8 includes theapparatus of example 1, wherein the plurality of processors, the CANBus, and region controller form a first compute module, wherein thefirst compute module is coupled to one or more other compute modules viaa CAN Universal Asynchronous Receiver-Transmitter (UART) multiplexercoupled to the CAN Bus. Example 9 includes the apparatus of example 1,wherein a motherboard comprises the plurality of processors, the CANBus, the region controller, and memory.

Example 10 includes the apparatus of example 1, wherein each of theplurality of processors is coupled to the CAN Bus via a serial bus.Example 11 includes the apparatus of example 10, wherein the serial buscomprises a Universal Serial Bus (USB). Example 12 includes theapparatus of example 1, further comprising a plurality ofmicrocontrollers, wherein each of the plurality of processors is coupledto the CAN Bus via one of the plurality of microcontrollers. Example 13includes the apparatus of example 1, wherein one or more of theplurality of the processors comprise a plurality of processor cores.Example 14 includes the apparatus of example 1, wherein a System On Chip(SOC) device comprises the plurality of processors, the regioncontroller, an interface coupled between the plurality of processors andthe CAN Bus, and memory.

Example 15 includes the apparatus of example 1, wherein an Internet ofThings (IoT) device or vehicle comprises one or more of: the firstcompute module and memory. Example 16 includes the apparatus of example1, wherein a single integrated device comprises one or more of: theplurality of processors, the region controller, and an interface coupledbetween the plurality of processors and the CAN Bus, and memory. Example17 includes the apparatus of example 1, wherein the high speed interfacecomprises an Ethernet interface.

Example 18 includes one or more computer-readable medium comprising oneor more instructions that when executed on at least one processorconfigure the at least one processor to perform one or more operationsto: communicate with one or more components of a vehicle via aController Area Network (CAN) Bus; and communicate with a regioncontroller via a point-to-point interconnect, wherein the processor,having one or more processor cores, the CAN Bus, and the regioncontroller form a first compute module, wherein the region controller isto manage operations of one or more components of the first computemodule, wherein the processor is capable to communicate with a secondprocessor and one or more other components of the first compute modulevia a high speed interface, while the processor is capable tocommunicate with the one or more vehicle components via the CAN Bus,wherein the high speed interface is to provide faster data communicationthan the CAN Bus, wherein the region controller is coupled to a ChassisManagement Module (CMM), wherein the CMM is capable to controloperations of one or more components of the first compute module throughthe region controller.

Example 19 includes the one or more computer-readable medium of example18, wherein the one or more vehicle components comprise one or more of:a camera, a LIDAR, a radar, an Inertial Measurement Unit (IMU), or anultrasonic device. Example 20 includes the one or more computer-readablemedium of example 18, further comprising one or more instructions thatwhen executed on the at least one processor configure the at least oneprocessor to perform one or more operations to cause the CMM to: controlpower consumption of the one or more components of the first computemodule and one or more other compute modules; monitor power consumptionof the one or more components of the first compute module and the one ormore other compute modules; or monitor temperature values for the firstcompute module and the one or more other compute modules.

Example 21 includes an apparatus comprising means to perform a method asset forth in any preceding example. Example 22 includes machine-readablestorage including machine-readable instructions, when executed, toimplement a method or realize an apparatus as set forth in any precedingexample.

In various embodiments, the operations discussed herein, e.g., withreference to FIG. 1 et seq., may be implemented as hardware (e.g., logiccircuitry or more generally circuitry or circuit), software, firmware,or combinations thereof, which may be provided as a computer programproduct, e.g., including a tangible (e.g., non-transitory)machine-readable or computer-readable medium having stored thereoninstructions (or software procedures) used to program a computer toperform a process discussed herein. The machine-readable medium mayinclude a storage device such as those discussed with respect to FIG. 1et seq.

Additionally, such computer-readable media may be downloaded as acomputer program product, wherein the program may be transferred from aremote computer (e.g., a server) to a requesting computer (e.g., aclient) by way of data signals provided in a carrier wave or otherpropagation medium via a communication link (e.g., a bus, a modem, or anetwork connection).

Reference in the specification to “one embodiment” or “an embodiment”means that a particular feature, structure, and/or characteristicdescribed in connection with the embodiment may be included in at leastan implementation. The appearances of the phrase “in one embodiment” invarious places in the specification may or may not be all referring tothe same embodiment.

Also, in the description and claims, the terms “coupled” and“connected,” along with their derivatives, may be used. In someembodiments, “connected” may be used to indicate that two or moreelements are in direct physical or electrical contact with each other.“Coupled” may mean that two or more elements are in direct physical orelectrical contact. However, “coupled” may also mean that two or moreelements may not be in direct contact with each other, but may stillcooperate or interact with each other.

Thus, although embodiments have been described in language specific tostructural features and/or methodological acts, it is to be understoodthat claimed subject matter may not be limited to the specific featuresor acts described. Rather, the specific features and acts are disclosedas sample forms of implementing the claimed subject matter.

1. (canceled)
 2. A vehicle comprising: a plurality of regions, whereineach of the plurality of regions includes one or more components of thevehicle; a plurality of region controllers, wherein each of theplurality of regions includes one of the plurality of regioncontrollers, wherein each of the plurality of regions is coupled toother regions of the plurality of regions via a single region controllerfrom the plurality of region controllers; and communication logiccircuitry to communicatively couple the plurality of region controllersvia a plurality of communication interfaces, wherein each pair of theplurality of region controllers are to communicate via at least one ofthe plurality of communication interfaces, wherein the one or morecomponents of the vehicle are capable to communicate via a ControllerArea Network (CAN) Bus.
 3. The apparatus of claim 2, further comprisinga master controller, coupled to the plurality of region controllers, tomanage operations of the one or more components of the vehicle.
 4. Theapparatus of claim 2, wherein the plurality of communication interfacescomprise a plurality of point-to-point interconnects.
 5. The apparatusof claim 4, wherein the point-to-point interconnect comprises anEthernet interconnect, a Universal Asynchronous Receiver-Transmitter(UART) interface, a Universal Serial Bus (USB), or an Interface toCommunicate (I2C) interconnect.
 6. The apparatus of claim 2, wherein thecommunication logic circuitry is to provide a communication channel withthe one or more components of the vehicle in each of the plurality ofregions via a corresponding region controller from the plurality ofregion controllers.
 7. The apparatus of claim 2, wherein the one or morevehicle components comprise one or more of: a camera, a Light DetectionAnd Ranging (LIDAR) sensor, a radar, an Inertial Measurement Unit (IMU),or an ultrasonic device.
 8. The apparatus of claim 2, wherein theplurality of communication interfaces are to provide faster datacommunication than the CAN Bus.
 9. The apparatus of claim 2, whereineach of the plurality of region controllers is coupled to a ChassisManagement Module (CMM), wherein the CMM is to: control powerconsumption of the one or more components of the vehicle; monitor powerconsumption of the one or more components of the vehicle; or monitortemperature values for the one or more components of the vehicle. 10.The apparatus of claim 2, wherein the communication logic circuitrycomprises a Peripheral Component Interconnect express (PCIe) switch,coupled to each of the plurality of region controllers, to facilitatecommunication between the plurality of regions and one or more PCIeconnectors
 11. The apparatus of claim 10, wherein the one or more PCIeconnectors are coupled to one or more of: a Field-Programmable GateArray (FPGA), a Graphics Processor Unit (GPU), a hardware accelerator orApplication Specific Integrated Circuit (ASIC) device, or a processor.12. The apparatus of claim 2, wherein an Internet of Things (IoT) deviceor the vehicle comprises a System On Chip (SOC) device, wherein the SOCdevice comprises one or more of: the plurality of region controllers,the communication logic circuitry, and memory.
 13. The apparatus ofclaim 2, wherein the plurality of communication interfaces comprise atleast one Ethernet interface.
 14. An apparatus comprising: a pluralityof region controllers, wherein each of a plurality of regions in avehicle includes one of the plurality of region controllers, whereineach of the plurality of regions includes one or more components of thevehicle, wherein each of the plurality of regions is coupled to otherregions of the plurality of regions via a single region controller fromthe plurality of region controllers; and communication logic circuitryto communicatively couple the plurality of region controllers via aplurality of communication interfaces, wherein each pair of theplurality of region controllers are to communicate via at least one ofthe plurality of communication interfaces, wherein the one or morecomponents of the vehicle are capable to communicate via a ControllerArea Network (CAN) Bus.
 15. The apparatus of claim 14, furthercomprising a master controller, coupled to the plurality of regioncontrollers, to manage operations of the one or more components of thevehicle.
 16. The apparatus of claim 14, wherein the plurality ofcommunication interfaces comprise a plurality of point-to-pointinterconnects.
 17. The apparatus of claim 14, wherein the point-to-pointinterconnect comprises an Ethernet interconnect, a UniversalAsynchronous Receiver-Transmitter (UART) interface, a Universal SerialBus (USB), or an Interface to Communicate (I2C) interconnect.
 18. Theapparatus of claim 14, wherein the communication logic circuitry is toprovide a communication channel with the one or more components of thevehicle in each of the plurality of regions via a corresponding regioncontroller from the plurality of region controllers.
 19. The apparatusof claim 14, wherein the one or more vehicle components comprise one ormore of: a camera, a Light Detection And Ranging (LIDAR) sensor, aradar, an Inertial Measurement Unit (IMU), or an ultrasonic device. 20.The apparatus of claim 14, wherein the plurality of communicationinterfaces are to provide faster data communication than the CAN Bus.21. The apparatus of claim 14, wherein each of the plurality of regioncontrollers is coupled to a Chassis Management Module (CMM), wherein theCMM is to: control power consumption of the one or more components ofthe vehicle; monitor power consumption of the one or more components ofthe vehicle; or monitor temperature values for the one or morecomponents of the vehicle.
 22. The apparatus of claim 14, wherein thecommunication logic circuitry comprises a Peripheral ComponentInterconnect express (PCIe) switch, coupled to each of the plurality ofregion controllers, to facilitate communication between the plurality ofregions and one or more PCIe connectors
 23. The apparatus of claim 22,wherein the one or more PCIe connectors are coupled to one or more of: aField-Programmable Gate Array (FPGA), a Graphics Processor Unit (GPU), ahardware accelerator or Application Specific Integrated Circuit (ASIC)device, or a processor.
 24. The apparatus of claim 14, wherein anInternet of Things (IoT) device or the vehicle comprises a System OnChip (SOC) device, wherein the SOC device comprises one or more of: theplurality of region controllers, the communication logic circuitry, andmemory.
 25. The apparatus of claim 14, wherein the plurality ofcommunication interfaces comprise at least one Ethernet interface. 26.One or more non-transitory computer-readable media comprising one ormore instructions that when executed on a processor configure theprocessor to perform one or more operations to cause: a plurality ofregion controllers to communicate with each other and/or one or morecomponents of a vehicle, wherein each of a plurality of regions in thevehicle includes one of the plurality of region controllers, whereineach of the plurality of regions is coupled to other regions of theplurality of regions via a single region controller from the pluralityof region controllers; and communication logic circuitry tocommunicatively couple the plurality of region controllers via aplurality of communication interfaces, wherein each pair of theplurality of region controllers are to communicate via at least one ofthe plurality of communication interfaces, wherein the one or morecomponents of the vehicle are capable to communicate via a ControllerArea Network (CAN) Bus.
 27. The one or more computer-readable media ofclaim 26, further comprising one or more instructions that when executedon the one processor configure the processor to perform one or moreoperations to cause a master controller, coupled to the plurality ofregion controllers, to manage operations of the one or more componentsof the vehicle.
 28. The one or more computer-readable media of claim 26,wherein the plurality of communication interfaces are to provide fasterdata communication than the CAN Bus.